1. Technical Field
This invention relates to an interface between a first network operating in accordance with a first transmission protocol and having network addresses in accordance with a first addressing convention, herein referred to as first type addresses, and a second network operating in accordance with a second transmission protocol and having network addresses in accordance with a second addressing convention, herein referred to as second type addresses; and to the tunnelling of packets across the second network from one such interface to another such interface; and relates particularly, but not exclusively, to communication between hosts in respective Internet Protocol version 6 (IPv6) domains separated by an Internet Protocol version 4 (IPv4) domain.
Herein, the terms packet and message are used interchangeably and have the same meaning, and the term Internet domain is used as a specific example of a network.
2. Related Art
In Internet technology, it had become apparent that the initial transport protocol, IPv4, needed to be enhanced, principally to increase the available address space and add a hierarchical address structure. The result was IPv6 which has a simplified header format compared with IPv4, but which uses 128 bit addresses as compared with 32 bit addresses used in IPv4.
Readers wishing to have an overview of this general transitional area might like to access a list of Internet-Drafts, which are working documents of the Internet Engineering Task Force (IETF), at http://www.ietf.org/1id-abstracts.txt, and a particularly relevant document is “A Guide to the Introduction of IPv6 in the IPv4 World” <draft-ietf-ngtrans-introduction-to-ipv6-transition-01.txt>, also referred to as “Guide to IPv6 Transition”.
As mentioned, the present invention relates to tunnelling. Known tunnelling techniques are of two types: configured and automatic.
A configured tunnel is created by manual configuration of a tunnelling interface between an IPv6 domain and an IPv4 domain such that all packets received from the IPv6 domain are encapsulated in IPv4 packets addressed to a specific tunnel end point, i.e. the tunnelling interface between the IPv4 domain and the remote IPv6 domain containing the destination IPv6 host.
An automatic tunnel on the other hand does not need manual configuration: the tunnel and points are automatically determined. Several automatic tunnelling mechanisms are currently in development within the IETF, these being known in the art as, 6over4, 6to4, Dynamic Tunnelling, and Tunnel Broker.
For more detailed information on 6over4 the reader can obtain from the IETF, the document known as RFC2829, or any variant thereof, “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels”, by B. Carpenter and C. Jung, March 1999.
For more detailed information on 6to4 the reader can obtain from the IETF, the document known as draft-ietf-ngtrans-6to4-02.txt, or any variant thereof, “Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels”, by B. Carpenter and K. Moore.
For more detailed information on Dynamic Tunnelling the reader can obtain from the IETF, the document known as draft-ietf-ngtrans-dti-00.txt.
For more detailed information on Tunnel Broker the reader can obtain from the IETF, the document known as draft-ietf-ngtrans-broker-00.txt.
These known automatic tunnelling mechanisms use a variety of techniques to enable the tunnel to be automatically established:                6over4 Multicast        6to4 Special IPv6 address in which the top level aggregator (TLA) contains an identifier for the 6to4 tunnelling mechanism, and the next level aggregator (NLA) contains the IPv4 address of the tunnel end point        Dynamic Tunnelling via DNS        Tunnel Broker www based tool        
European patent application EP 840 482 discloses a method of communicating between an IPv4 terminal and an IPv6 terminal, in particular a method of performing protocol conversion on IPv4 packets and IPv6 packets using converting apparatus located between IPv4 and IPv6 networks. EP 840 482 states that there are several known methods for communicating between IPv4 and IPv6 terminals, and discusses the aforementioned tunnelling methods, among others. EP 840 482 asserts that there are several problems with these existing methods, and accordingly provides a new method for IPv4-IPv6 internetworking. Their method is explained by means of an example: considering the case of an IPv4 terminal C requesting communications with an IPv6 terminal A. The IPv4 terminal sends a name lookup request for a host A in the IPv6 network. This request is received by the converting apparatus, which forwards the request to a DNS server. The DNS server returns an IPv6 network address to the converting apparatus, which assigns an IPv4 address from a pool of addresses (from a Dynamic Host Configuration Protocol (DHCP) server) to the returned IPv6 address. The converting apparatus stores the mapping between the assigned IPv4 address and the returned IPv6 address, and forwards the assigned IPv4 address to the requesting host C. In subsequent communications between hosts C and A, host C sets the destination address to be the assigned IPv4 address for outgoing packets, and sends the packets to the assigned IPv4 address of Host A; conventional IP routing ensures that the packet routes to the converting apparatus. The converting apparatus then looks up the mapping between assigned IPv4 address and IPv6 address to retrieve the IPv6 address of host A, and makes this the destination address of the packet.
EP 840 482 thus presents a new method of IPv4/IPv6 networking.